IBIS Macromodel Task Group Meeting date: 04 August 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to investigate the current relevance of tabled item 15. - Done. - Arpad to email Greg Edlund to ask about his current thoughts on his DLL error trapping topic (item 16). - Done. No reply from Greg yet. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Curtis: I received no feedback via email for last week's minutes. - Mike L.: Motion to approve the minutes. - Bob R.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: - Arpad: Motion to untable item #15 (Info, Out, InOut BIRD). - Radek: Second. - Arpad: Anyone opposed to untabling item #15? [none] - Arpad: [sharing draft #10 from the work archives - June 2011] - We had worked on this actively at one point. - It was still referring to IBIS 5.0. - I reviewed it with respect to IBIS 6.0. - There were two issues. - 1. Many AMI reserved parameters' descriptions didn't specify which function call, AMI_Init() or AMI_GetWave(), would return their values in AMI_parameters_out. - In IBIS 6.0, the reserved parameters are now fully described. - This issue seems resolved in IBIS 6.0. - In the recent PAM4 BIRD, we seem to have forgotten this issue. The PAM4 BIRD contains several parameters for which the function returning the value is not specified. There was a discussion of this on the reflector, and Walter proposed some new language to resolve this issue. Editorial can fix this. - 2. Issue with Model Specific Out parameters. - How does the tool know what to do with them? - The goal was to limit what tools can do with such data. - This part of the BIRD still seems valid (even with IBIS 6.0). - Radek: My recollection is that we all agreed EDA tools can't take specific steps based on Model Specific parameters except for displaying the info to the user. This raised the issue of whether processing of such Model Specific parameter information is specification compliant. We did not finish those discussions. - Walter: I think the specification is a description of what the model does. - It should have nothing to do with what a tool should do with the model. - The parser couldn't check for such a rule, so it can't be verified. - Todd: The issue is portability between tools. - Arpad: Yes. - IBIS has lots of rules that aren't enforceable by the parser. - Todd: Question is, what is the current AMI Contract? - Currently we don't describe all the things an EDA tool should do. For example, we don't describe how it should use clock ticks data. - Describing everything a tool should do would be a huge undertaking. - But we do have a non-trivial issue with model portability. - If a model has a Model Specific Info or Out parameter: - Do we want to outlaw its use by EDA tools? - Or, do we want to make it clear that a model with that feature has portability issues? - Do we want to legislate what EDA tools can do? - Arpad: The goal is not to legislate what a tool can do. - You can do what you want for special features. I can do what I want. But for portability and interoperability reasons, we can't call it compliant. - Bob R.: If they're represented as Model Specific parameters, they are IBIS compliant syntactically. - If they use Info or InOut Model Specific parameters they are EDA vendor specific. - Todd: Doesn't that go against the use of "standard"? - Bob R.: No, it is syntactically compliant with IBIS. - Walter: Suppose an IC vendor makes a model with an Output Model Specific parameter that provides the number of Watts the model is consuming. Depending on how many DFE taps, etc., it might determine the power the device is consuming. Documentation that goes along with this model says that this parameter provides the number of Watts the device is consuming. - Many of our tools allow us to optimize such a parameter. - Nothing unreasonable for a tool to use that model in a compliant way and do simulations. - User may want to make trade-offs with that parameter. - Can go one step further and want the tool to automatically run a bunch of simulations and modify configurations to minimize power, etc. - Ambrish: Do you expect the EDA tool to read the documentation? - Walter: No, I expect the user to read the documentation and tell the tool what to do. - Todd: What Walter has described isn't custom, but it's not germane to the problem at hand. - The concern here is where the simulator is expected to automatically know what to do with a Model Specific parameter. - Ambrish: Right, with what Walter has described the user decides what the tool has to do to use that parameter. - Bob M.: Walter is proposing that if there's some Model Specific parameter, and the user reading the documentation decides he wants to optimize it, then they should be able to have the tool run simulations to see how it is affected by other variables and controls. There's nothing specific about that optimization. - Ambrish: That's a sweep type simulation. You can always do that. - This BIRD is talking about the tool taking the output value and using it to modify then next input waveform. - Bob: It's more of a directed search where the EDA tool can make decisions about what to do next based on the value of this parameter. - Arpad: This optimization example is a useful one. - However, it's just one of an infinite number of possibilities. - Todd: Is the core objection that Model Specific things are being called compliant and standard? - Arpad: If we allow these Model Specific behaviors in the specification, then we are undermining the specification itself. - Todd: Anything that affects the way the simulator simulates or processes the results from a model either needs to be a Reserved parameter or needs to be called out as special. - It's a legitimate concern that a model putting out something not defined or interpreted universally will affect the portability of the model and undermine the standard. - Do you say you can't do it? - Do you say, "you're working outside the spec"? - I'm inclined to think if you want a Model Specific parameter "Framis" and want the model and EDA tool to go do something specific, then go for it. - They often become prototypes for things that end up in the standard. - But, it's legitimate to say that thing should be a Reserved parameter and isn't, so it will not be portable. - Ambrish: How would you distinguish what is and isn't? - Radek: The user must know and understand the possible extended interpretation. - Ambrish: That doesn't happen. The user sees a model and expects it to work. - Radek: That's because we don't have a mechanism for explaining it. - Maybe we want to have an announcement in the AMI file that it is potentially non-compliant. - Ambrish: What's the incentive for them to do that? - Radek: It's legitimate information for the user. - Or the EDA platform that is doing something with a Model Specific parameter to influence the simulation should inform the user. - The user may not know and may be surprised by that. - Ambrish: We've recently seen models that were compliant in that they passed the parser. But they used methods that were discussed and not approved by the Open Forum. - Todd: I believe that people will do what they need to do to get the job done. - But, I think it's useful for people to understand quickly if something is part of the standard or if it is a non-portable extension. - Ambrish: One way would be to publicly out those models on the Open Forum. - Arpad: One of the problems, as Walter pointed out, is that we can't enforce it. - We have other rules that can't be enforced by the parser. - The spec says the input waveform to GetWave() should be +-0.5V. - The parser can't check that, and a user might find out the hard way, but if an EDA tool provides an input waveform that isn't +-0.5V we can say it isn't compliant with the spec because it's doing something different. - Todd: The word "compliant" has become emotional and political. - What might be productive is that we adopt a convention where if you're using extended syntax there's a way that you identify that in the AMI file. - Someone looking at the AMI sees where you're doing something specific to a particular tool. - That enables the discussion about, "why did you have to do that?" - John: Would the power dissipation model parameter (Walter's earlier example) have to be labelled special syntax? - Todd: Not unless you expect the simulator to do something special with it. - John: Would the simulator having the facility for an optimization process based on AMI parameters identified by the user, and the user identifying such a model specific parameter in that facility, then raise that parameter to needing to be called out as special syntax. - Todd: I would argue no. What Walter described is classic optimization. - John: I agree. - Todd: A parameter that modifies the way the driver or receiver model is to be processed or used, that is not part of the spec, is an example of something that would require special identification. - John: The tstone file parameter is such an example. - Ambrish: That would also apply to an Info parameter, not just an Out. - Arpad: Why is adding a statement that it is non-compliant viewed negatively? - You have a non-compliant feature, but that could be because you're a pioneer and you've invented something new. - If the model says unequivocally that this is something special and outside the box, then the user would know they can't just drop it into any tool. - That avoids problems for the other EDA tools that don't support it. - Walter: IC vendors work hard to generate models that work on many tools. - Sometimes they can't have some functionality, and we come back and create a BIRD for it. - We did that for the PAM4 BIRD. - When there's a new parameter and the IC vendor needs it to work on all tools then they come and add it to the standard. - Radek: The only real issue is the user should know about it. - That's the interpretation by the EDA tool. - If the other tools ignore a special parameter and take some different more standard approach the user doesn't know. - The user should be informed. - Ambrish: At a minimum the user should be informed. - At best the model should comply with the standard if there's a standard way of achieving the same result. - Todd: If you're using syntax beyond the standard you should tell the user why. - I'm happy to help define the conventions we should all use for doing so. - How do we want to handle this? How do we want vendors and model makers to identify a simulator specific function that's not part of the Reserved AMI parameter space? - Arpad: Now is a good stopping point. - Let's all think about that question and come back next week. - Thank you all for joining. ------------- Next meeting: 11 August 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives